不確定其他行業之間的轉換是否也如此艱辛，但我記得轉職後的前幾個月痛不欲生。
現在看新人處理事情當機時的呆滯表情，我笑得多開心，之前我自己遇到相同困難就有多痛苦。
對跨領域轉職PM來說，需能快速歸納待辦事項只是基本款，最大挑戰是須狼吞虎嚥海量般的陌生知識，吃不下還是得強迫自己硬塞，腦袋過載疲倦還是只能靠自救。

學完新知當下立刻以自己的方式復述內容

很多人學習的習慣是立刻寫下筆記，記錄固然重要但順序是重點。
首先因為這是新學到的知識，你有把握寫下的筆記是正確內容嗎？會不會老師說MongoDB，你的筆記本只寫到形似的Mango？
剛討論完一件事，特別是自己新接觸很不熟悉的狀況下，無論是口說，或以文字、圖像等白字黑字的紀錄更好，將自己理解的內容立刻講一次給傳遞資訊給你的人聽，請對方確認你的認知是否有落差。
我的習慣是他人在敘述時，我寫畫的內容並非流水帳、而是我「思考轉譯過」的表達內容。
例如工程師解釋一個功能優化可能說：
「我要加一個temp table存審核資訊，因為A功能先XX，接著B功能批次審核，然後C功能XX⋯⋯這樣中間那一段處理失敗了也不會整體掛掉。」
我的筆記本可能會依據敘述畫出一個簡單流程圖，如下圖，給工程師看並反問：「所以是在紅色的這個地方增加temp table，獨立B功能讀取的table以防影響到其他功能嗎？」

很多人敘述時會夾雜很多「代名詞」，究竟他人的「整體」是A+B+C還是A+C而已，只有綜觀整理後，大家一起來指認定義才會清楚。
PM特別常遇到類似的需求定義問題，資訊轉譯方式同樣能運用在自己學習新知時的驗證，如果自己無法轉化學到的資訊，肯定是哪裡不清楚卡住了。

確認未參與討論的第三者能否聽懂

跟敘述事情的本人確認完，不一定代表自己從根本弄懂了問題，也許有很多地方說明得不到位或忽略了，但對方畢竟是徹底理解這件事的人，稍微敘述不精準還是可以聽懂。
未參與討論的第三者對故事源由、問題發生情境等細節一概不知，能闡述到第三者都能聽懂問題，代表敘述內容客觀有重點。
如果一樣的敘述講給不在場的主管、客戶等人，他們反問時若無法進一步解答他們，就是還有需深掘之處，需要再回頭請教釐清問題了。
和不知情的第三者能討論出來的共識，記得確實留下文書紀錄，圖文並茂為佳。未來回頭檢視時，即使大家記憶消散，還可以看得懂並回想問題是最好的。

前輩傳授的經驗多參考但仍需質疑

好的前輩用正確方式帶你長大，只能說你抽中了上上籤，事實上多得是前輩帶歪後輩的例子。
但仍建議「前輩提供的經驗只能參考」，每個人適合的學習模式不同，更何況好人不一定是好學生，好學生不一定是好老師，有的人自帶外掛技能但可能會教爛別人，即使有善良的前輩引導，記得要多方驗證前輩所教是否正規正確。
驗證方式有很多種，我自主考取國際證照就是其中一種，想看看前輩所教與國際標準有無差異。（詳細心得可參考《轉職好迷茫，考證照會對PM有幫助嗎？》）
也可以詢問多方意見，尤其建議多傾聽「跨部門」聲音。
PM的主張不一定絕對正確，客戶、分析師、工程師、客服、行政的做事風格和考量各有不同，以專案來說，合約範疇內能讓一件事促成多方雙贏才是最佳解法，就可依此推敲修正做事方法。
前輩有時累了也會說錯話，多提問質疑也許能幫助彼此思考（不過要有藝術的質疑，口氣不好只會被當成白目），很多新的更好的解法都是在brainstorming激發出來的。

上述方法，個人覺得不僅適用於「自我檢視」，也很適合「考驗新人」。
現在我常用的一招是不聽不看工程師的回報，請新人去了解工程師的說明，新人消化過後再轉述、負責讓我聽得懂事件內容，因此debug出蠻多新人僅僅「傳話」而未「思考轉述」問題。雖然花時間，但陷入僵局時再交叉比對工程師和新人的說詞，對工程師、新人察覺自身表述方式有問題的部分也頗有幫助。